[t:/]$ 지식_

백단의 백단

2020/05/27

(나는 고성능 컴퓨팅쪽에 취미가 있다.)

나는 줄곧 백단의 백단을 따로 구분해야 한다고 주장하는 편인데.. (뭐 주장만 하고 실현은 못함..) 사연은 이렇다.

하둡이나 기타 클러스터 기반 대용량 처리를 하는 자원이 있다. 프론트에서 500ms 응답 이러고 자빠져있으면 108계단 18콤으로 쳐맞는다. 그러니 빠르게 응답한다고 피닉스를 붙이고 임팔라를 붙이고 ES를 붙이고 뭐 그런다. 이론상 실험상 오또상 속도도 잘 나온다. 그러면 나는 말한다. 에이 그러면 안 되부러요... 와스에 얘네들 직빵으로 달믄 망한당게요.. 망해부러.. 아믄..

클러스터에 붙어있는 작업자들은 클러스터를 무한한 자원이라고 여기기 쉽다. 안 그런데 그런다. 그런데 사실 안 그렇다. 우리는 아마존이 아니고 구글이 아니다. 중규모 클러스터에서도 대규모 데이터를 다루는 건 흔한 일이다. 아마존을 쓰면 되잖아? 아 저도 쓰면 좋겠죠..? ...뭐 임마?

물론 쿼리 튜닝을 한다. 책도 읽고 구글도 본다. 파이썬 코드를 최적화한다. 그런데 그건 그냥 일부다. 디씨의 악플러 중 하나를 잡은 거라고.

응집도가 높은 업무가 있다. 업무 도메인의 일관성이 높다는 듯이다. 개편하고 추가하는 일이 있어도 하는 일은 비슷하다. 요구 자원의 총량이 확 튀거나 확 쭐지 않는다. 그런 일이 있다면 예측이 가능하다.

다양성이 높은 회사가 있다. 커머스도 하고 광고도 하고 뭐 돈 된다고 했다 접었다 그냥 다 해주세요 그런다. 갑자기 쌩뚱한 쿼리들이 등장하고 요구 자원의 총량은 튀고 피나고 쳐맞고 그런다. 뭔 일이래요? 예측이 가능할만도 한데, 계가 복잡하여 덮어둔다.. 아몰러.. SI식으로 엄밀하게 기획된 도메인이 아니라면, 사업 영역이 좁고 정확하게 잡혀있는 회사가 아니라면 보통 이렇다.

요구 자원의 총량이 추정 가능하고 일관된 편이거나, 아마존 쓰면 되져 하는 편이라면 백단의 백단을 구분하는 일이 필요없을 수도 있겠다. 그런데 우리는 타바코쥬스자나? 안 될꺼야 아마. 우리에게 미래는 없는 것이다..

너님도 나님도 무한한 자원을 생각하고 코드를 때리고 있지만 클러스터가 허덕대기 시작한다. 아니 왜? 평소엔 남아돌잖아? 아니 그건 그 때 이야기죠. 지금은 아니랑께요? 야 씨 응답 지연 알람 오자나. 오메 마스터 뻗어부럿다는데요? 아니 클러스터 쓰면 삼중화 사중화 장애 관리 빼일 오버 완벽하다뭬??

그리하야 나는 이렇게 복잡도가 높은 시스템은 백단의 백단으로 취급해야 한다는 것이 나의 오래된 생각인 것이다.. 레디스든 몽고든 삼별초든 와스랑 직빵 붙을 놈들은 뭔가 빠닥빠닥해야 한다는 것이다..

인류의 IT 역사가 원래 그랬다. 쓰리 티어 갔다가 미들웨어 갔다가 클라서버 갔다가 다시 쓰리 티어 갔다가 하는 것이여.. 차세대는 전전세대 모델로 가시죠? 오.. 진짜? 굿 아이디어!





공유하기













[t:/] is not "technology - root". dawnsea, rss